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Abstract. The establishment of a National Spatial Data I nfrastructure represent significant 
added value as leader initiative, to facilitate access to spatial data beyond the boundaries 
between organizations (public and private); ensure the diffusion and promotion of 
geographic information; sharing of expertise; acquisition and provision of geographic 
products and databases; the identification of existing spatial data and metadata; and 
improving accessibility and interoperability ...etc. 

Beyond the inescapable statutory definition, this approach is part of a dynamic pooling, 
which will have a significant impact on the way will be used geographic information systems 
identified within the producer organisms of geospatial data. 
The National I nstitute of Cartography and Remote Sensing (I NCT) as the largest producer of 
Geographic Information in Algeria, has initiated a national reflection around the NSDI 
through the organization of the first National Conference in October 2012. Many 
recommendations were adopted, of which the necessity of establishing a National Spatial 
Data Infrastructure was strongly solicited. 

To consolidate this initiative, an ambitious project on the definition of a methodological 
approach of the development of Algerian NSDI, was recently launched and registered as a 
research project in the I NCT. This research presents the results of works on the definition of 
a methodological approach for the development of a NSDI according to international 
standards (ISO, W3C, OGC, OMG) enriched by a space dictionary adapted and the 
establishment of a geoportal around the open source software as (Easy SDI , Geoserver and 
Geonetwork). 

The work was carried out in two phases: the first phase is to understand the anatomy of the 
SDI and adapted it by creating an Algerian profile based on an architecture which defines a 
full life cycle of a project including all phases and activities according the unified process 
(openUP) usi ng the metamodel SPEM (Software Process Systems & Engineering Metamodel) 
and UML. The second phase has led to the development of an application using Open source 
software. 

Keywords: I NCT, I SO 19115, NSDI of Algeria, Opensource, SPEM, openUP 



1. Introduction 

Nowadays several projects of Spatial Data I nfrastructure (SDI ) emerge at different territorial 
levels. These initiatives facilitate the exchange and use of geographic information in a 
perspective of knowledge and sharing. 

The establishment of a spatial data infrastructure represents an added value to facilitate 
access to spatial data across the borders of organizations. 

This solution guarantees: 

- The inventory of existing spatial data and the improvement of accessibility and 
interoperability; 
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- The dissemination and promotion of geographic information; 

- The sharing of know-how; 



1. components 

A geospatial data infrastructure includes spatial data sets, metadata, and network services 
that enable research, evaluation, visualization, and judicious use of shared data. 
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Figure L Components of an SDI 

Figure 2 provides a simplified overview of the key elements of the technical architecture of a 
SDI. Being the central resource content (Spatial Dataset), ie geospatial data available as 
datasets. All other resources shown, I ike metadata, is only necessary to find, access, interpret 
and use objects in spatial datasets as part of the infrastructure [INSPIRE 2007]. 
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Figure 2. Technical architecturediagramof a SDI [INSPIRE 2007] 
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1.2. Datasets 



In a data set each spatial object must be described by specifications defining its semantics 
and characteristics. The types of spatial objects provide their classification, and determine all 
other properties (thematic, spatial, temporal, etc ...) that any spatial object may have, as well 
as a number of known constraints. I n principle, this information is captured in an application 
schema conforms to the specifications of the [ISO19109] standard and formalized in a 
conceptual schema using the [OMG/ UML] notation. 

The technical specifications of the datasets are prepared in accordance with [IS019131] and 
[ISOBBVAmdl]. 

1 .3. Network Services 

Network services are necessary for sharing spatial data between stakeholders in a SDI. 
Therefore, the interoperability problems must be defined in advance to allow services to 
i nteract wi thout repeti ti ve man ual i nterventi on . 

To achieve this goal, the technical specifications of the SDI 's network services must define the 
interfaces by which different parts of the infrastructure will communicate. I n principle, this is 
done by a conceptual schema, defining a web service, conforms to the specifications of the 
W3C/WSDL [WSDL 2.0] and the [IS019119] standards and using the [OMG / UML] 
notation. 

1 .4. Metadata 

M etadata provi de i nformati on necessary to discover and spati al data sets they descri be. 

In addition, the metadata service provides basic information about a service instance. The 
service description includes the type of service, a description of the operations and their 
parameters as wel I as i nformati on on the geographi c data avai I abl e. 

The technical specifications are formalized as a metadata profile derived from the [I SO 19115] 
and [IS019119/Amdl] standardsin aconceptual schema using the [OMG/ UML] notation. 

1.5. Process model selection 
1.5.1. classification of processes 

A process is a sequence of tasks and activities designed for the development of a software 
intensive system. To choose the appropriate process model we have to compare the features 
of the current project with the characteristics of different process models and choose the 
most appropri ate one. Tabl e- 1 1 i sts the characteri sti cs of proj ects by combi ni ng them to a wel I 
known process models. 





Agile 


Plan- Driven 


o 
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- Project is small (5-10 people). 


- Project is large (more than 10 people). 


- Experienced teams with a wide range of 


- Teams include varied capabilities and skill sets. 


eg 


abilities and skills take part. 
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- Project is of strategic importance (e.g., an 


o 
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- System is new, with lots of unknowns. 
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- End-user environment is flexible. 


- System is large and complex, with critical safety or 
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co-located. 
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- High trust environment exists within the 
development teams, between the 
development teams, and with the customer. 

- Rapid value and high-responsiveness are 
required. 


formal certification against specific industry 
standards) exist 

- Focus is on strong, quantitative process 
improvement. 

- Definition and management of process are 
important. 

- Predictability and stability of process are important. 


Examples 


- extreme Programming (XP) 

- Scrum 

- DSDM 

- OpenUP 


- Personal Software Process (PSP) 

- Team Software Process (TSP) 

- Rational Unified Process (RUP) 

- Source [Wikiversity.org, 2012] 



Table L Agile and Plan-Driven Project Characteristics 



Given the foregoing, we considered that the use of an agile model, especially OpenUP, is most suitable 
for the definition of aGeospatial Data I nfrastructure development process, object of this work. 

1.5.2. OpenUP 

OpenUP is an agile development process, minimal and sufficient, containing a core set of best 
practices. It applies the phases of the Rational Unified Process (Inception, Elaboration, Construction, 
and Transition). Figure3 illustrates the sequence of theOpenUP delivery process. [Balduino 2007] 

I n addition, OpenUP is extensible, and serves as a base process upon which additional process content 
can be built. 
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Figure 3. OpenUP delivery process [Balduino 2007] 



2. Definition of the IDGProcess 

The development process I DGProcess, defined in the context of this work has been formalized in an 
[OMG/SPEM] notation, taking into consideration all the specifications issued by ISO / TC 211, OGC 
and W3C. 

The life cycle of the various components of a geospatial data infrastructure, including data, metadata 
and services, was highlighted in the process with, for each phase, the detailed definition of the tasks to 
be performed. 

2.1. Inception 

The inception phase is used to initiate the project and to identify its requirements. It aims to 
understand the main needs (what will be built), the identification of the key features of the system, 
determining at least one possible solution as well as the analysis of cost, time and risk associated with 
the project. 
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Figure4 below shows the tasks proposed for the I DGProcess inception Phase. 
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Figure 4. Inception Iteration - SPEM Diagram 

Phase "inception" includes two tasks namely: 

- Design BPMN diagrams. 

- Design use case diagrams. 
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Figure 5. Inception Iteration "Design business process diagram"- SPEM Diagram 
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Figure 6. Inception iteration "Use case diagram" - SPEM diagram 
2.2. Elaboration 

The elaboration accurately identifies the system requirements and defines its architecture. A 
preliminary solution is developed and tested at this stage. At the end of this phase, project managers 
must beableto plan activities and to estimate the resources required to complete the project. 

The objectives of this phase are: 

- Develop a more detailed understanding of the requirements; 

- Design, implement, validate, and test a basic architecture; 

- Mitigate essential risks, and produce a clear timetable estimate costs. 
Figure 7 below shows the tasks proposed for the I DGProcess Elaboration phase. 
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Figure 7. Elaboration iteration - SPEM diagram 

The "elaboration" Phase includes several tasks divided into three parallel lines, each one representing 
a component of the SDI to develop, namely the data, metadata and services. 

The mai n tasks of this phase are: 

1 The data: 

- Design the I SO 19 109 conformant application schemas; 

- Release the I SOBBlconformant data specifications; 

- Transform the application schemas to implementable data models (object oriented, relational or 
xml); 

- Administrate the implemented database and test some data. 

2. The metadata: 

- Design the [I SO 19 115] and [I S019119/ Amdl] conformant class diagrams of the Metadata profile; 
- 1 implement the metadata profi le i n the chosen geo-catalog. 

3. The services: 

- Design theW3C/WSDL and [IS019119] conformant class diagrams of the web services; 
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I implement the web services with the chosen programming language; 
Deploy the web services on the application server. 
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Figure 8. Elaboration Iteration "Design application schema diagram" - SPEM Diagram 



The figure below illustrates the process adopted for the preparation of the data specification document 
for external use. 
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Figure 9. Elaboration Iteration "Release data specifications document" - SPEM Diagram 
The figure below illustrates the process adopted for the administration of the databases. 
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Figure 10. Elaboration Iteration "Data Base Administration" - SPEM Diagram 



The figure below illustrates the process used to develop the metadata XM L schema (XSD). 
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Figure IL Elaboration Iteration "Design metadata class diagram"- SPEM Diagram 
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Figure 12. Elaboration Iteration "Metadata implementation" - SPEM Diagram 

The figure below illustrates the process adopted for the development of web services specificati 
accordi ng to the W3C standards. 
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Figure 33. Elaboration Iteration "Design web Service" - SPEM Diagram 
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Figure 14. Elaboration Iteration "Webs service implementation"- SPEM Diagram 
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Figure 35. Elaboration Iteration "Webs service deployment"- SPEM Diagram 
2.3. Construction 

The construction phase allows the effective achievement of the proposed system. The objective is to 
iteratively develop a complete product ready to be transferred to the client. 
Figure 16 below shows the proposed tasks of the construction phaseof SDI Process. 
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Figure 16. Construction iteration - SPEM diagram 
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The figure below illustrates the process proposed to test the various system components. 
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Figure 17. Construction Iteration 'Test system" - SPEM Diagram 

The figure below i I lustrates the process proposed to deploy the various components of the system. 
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Figure 38. Construction Iteration "System deployment" - SPEM Diagram 
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The figure below illustrates the process adopted for managing the changes in the development of the 
system. 
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Figure 39. Construction Iteration "Mange Changes"- SPEM Diagram 
2.4. Transition 

I n this phase, tests are performed to validate that the planned objectives have been achieved. At the 
end of these tests, the stakeholders agree on the completion of the deployment. 
Figure20 below shows the tasks proposed for the I DG Process Transition Phase. 
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Figure 20. Transition iteration - SPEM diagram 
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3. Validation 



To preliminarily validate the proposed process, a prototype of an Algerian NSDI was developed at the 
National I nstitute of Cartography and Remote Sensing (I NCT). 

This prototype takes the form of a geoportal based on the open community source project EasySDI 
[EasySDI .org]. It guarantees, among other things, the use of OGC Web Services like WMS and WFS 
previously published in the structures concerned. 

The deployment diagram, component diagram and the use case diagram of the system developed in 
the pilot project are detailed below. 

3.1. Presentation of the urban database 

Urban Database contains the main elements providing basic information of the geographical data 
including: frames, road network, road Node, administrative boundaries and geonames that are 
characterized by a number of properties. 

The Building and the Road Network layers contains attributes of the address and geoname themes. 
The Structure, the design and the integration of this database is inspired by several urban databases 
produced by different international organizations such as ISOTC2H INSPIRE, OGC and IGN, taking 
into account different local needs. 

Figure 21 illustrates the package diagram of the Urban Database designed as part of this work. 
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Figure 2LUrban database package diagram 
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Figure 22. Arborescence model of the application schema 
3.2. Building Class - Example 

Figure 23 illustrates the class diagram of the Building class designed in the context of this work. 



class Building 



•<featureType» 
Building 

+ Bui Idi ng Id : Integer 

+ BuildingName: CharacterString 

+ BuildingNum: CharacterString 

+ Commentary: CharacterString 

+ ConditionBuilding: CharacterString 

+ ElevationBuilding: Real 

+ Extent: GM_Surface 

+ FloorNumber: Integer 

+ GeometricAccuracy: Real 

+ GeometricSource: CharacterString 

+ Municipality: CharacterString 

+ PostalCodeBuilding: Integer 

+ StreetNameAdjacent: CharacterString 

+ TypeBuilding : CharacterString 

+ UsageOfBuilding: CharacterString 



Figure 23. Building class diagram 



Stereotype: featureType 
Model Element: class 

Attributes. (Buildingld, BuildingName, BuildingNum, TypeBuilding, PostalCodeBuilding, 
ElevationBuilding, ConditionBuilding, StreetNameAdjacent, Municipality, UsageofBuilding, 
GeometricSource, GeometricAccuracy, FloorNumber, Commentary, Extent). 
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Building spatial dictionary (in French) 



Attribut 


Description 


Type 


With 


Domain 


Buildingld 


Identifiant 


Integer 


6 




BuildingNum 


Numero de batiment lie a I'adresse communal 


Integer 


6 




PostalCodeBuilding 


Numero postal d'acheminement selon la liste 
off icielle 


Integer 


8 




BuildingName 


renseignent sur les noms des bailments. 


CharacterString 




* 


ElevationBuilding 


renseignent sur la hauteur, la position 
altimetrique du batiment. 


Real 


10 




ConditionBuilding 


Etat de bati 


CharacterString 


30 




TypeBuilding 


assure la differentiation semantique des 
DaTimenis. peux prenare les vaieurs 
Administratif, Industriel, agricole ou 
commercial, Religieux, Sportif,...etc 


CharacterString 


50 


** 


Extent 


Geometrie des objets 


GM_Surface 


(4,2) 




StreetNameAdjacent 


Norn de la rue adjacente 


CharacterString 


50 




Municipality 


Norn de la commune selon le decoupage 
administratif 


CharacterString 


50 




UsageofBuilding 


usage pour lequel le batiment est prevu : 
industriel militaire nar dps ptrannprs 


CharacterString 






(nPnmptrirSm irrp 


Source geometrique precise comment on a 
recupere le batiment 

PDV , image satellitaire, leve GPS 


CharacterString 


20 


*** 


GeometricAccuracy 


Precision geometrique planimetrique en metre 


Real 


(4,2) 


**** 


FloorNumber 


Nombre d'etage (-1,-2,R, 1,2, 3,4...) 


Integer 






Commentary 


Commentaire portant des informations peuvent 
etre utiles 


CharacterString 


150 





Table 2. Building spatial dictionary (in French) 
Geometry : surface. 

3.3. Projected architecture of the Algerian NSDI 

The deployment diagram in Figure 24 shows the overall architecture of the Algerian NSDI and 
precisely expresses the prototype developed. Other actors of the future national infrastructure will be 
integrated as soon as they set up their own infrastructure, the minimum being the establishment of 
their respective Geocatalog. 
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Figure 24. NSDI deployment diagram 



F igure 25 i 1 1 ustrates the Pri mary use case di agram of the Algeri an N SDI designed as part of thi s work. 



Figure 25. Primary use case diagram 

Figure 26 illustrates an example of a sequence diagram of the Algerian NSDI designed as part of this 
work. 
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Figure 26. Sequence diagram of server interrogation 
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Figure27 illustrates the components diagram of the developed application. 



Figure 27. Components diagram of the developed application - interconnections 



F i gure 28 i 1 1 ustrates the Depl oyment d i agram of the devel oped appl i cati on . 
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Figure 28- Deployment diagram of the developed application 



21 



3.4. User interface 

Figure 29 shows the homepage of the geoportal solution implemented with J oomlaand EasySDI. This 
webpage contains a menu allowing access to thewebmapping module (Figure 30), geocatalog module 
( F i gu re 3 1) and t he shop mod u I e ( F i gu re 32) . 
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Figure 29. H omepage of the geoportal 




Figure 30. Web mapping module 
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Figure 3L Catalog module 
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Figure 32. Shop module 



4. Conclusion and outlook 

The realization of this project has raised a number of questions and opened new fields of research and 
investigation in the field of geomatics. I ndeed, we necking our methodology to the core functionality of 
an SD I. The same applies to the development of the database schema; we have realized a small part for 
the first validation of our method. 

I n addition, it should be noted that the use of open source tools, such as EasySDI , allows a rapid and 
efficient development of complex systems with very low costs. However, their implementations require 
highly specialized skills in programming, a lot of patience and quite significant research efforts. 
For years, multiple perspectives must be considered, such as: 

- Refi ni ng the proposed process by its use i n other specific projects; 

- The integration of the developed process in the project "EPF" of the Eclipse Foundation; 

- The study of the legal aspects related to the implementation of spatial data infrastructures; 

- Experimenting XML databases for the storage of GML files and metadata; 

- The integration of theGeoDRM standard (digital rights management) on the services cycle. 
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